Avtomatizacija testiranja s Tox: Poglobljen pogled na testiranje v več okoljih za globalne ekipe

V današnji globalni programski pokrajini je fraza "deluje na mojem računalniku" več kot le razvijalski kliše; je pomembno poslovno tveganje. Vaši uporabniki, stranke in sodelavci so razporejeni po vsem svetu in uporabljajo raznoliko paleto operacijskih sistemov, različic Pythona in nizov odvisnosti. Kako lahko zagotovite, da vaša koda ni samo funkcionalna, temveč tudi zanesljivo robustna za vse, povsod?

Odgovor se skriva v sistematičnem, avtomatiziranem testiranju v več okoljih. Tukaj Tox, orodje za avtomatizacijo, ki ga poganja ukazna vrstica, postane nepogrešljiv del modernega nabora orodij razvijalca Pythona. Standardizira testiranje, kar vam omogoča, da določite in izvajate teste v matriki konfiguracij z enim samim ukazom.

Ta obsežen vodnik vas bo popeljal od osnov Toxa do naprednih strategij za testiranje v več okoljih. Raziskali bomo, kako zgraditi odporno testno cevovod, ki zagotavlja, da je vaša programska oprema združljiva, stabilna in pripravljena za globalno občinstvo.

Kaj je testiranje v več okoljih in zakaj je ključnega pomena?

Testiranje v več okoljih je praksa izvajanja vašega testnega paketa proti več, različnim konfiguracijam. Te konfiguracije ali "okolja" se običajno razlikujejo glede na:

• Različice tolmača Python: Ali vaša koda deluje na Python 3.8 tako dobro kot na Python 3.11? Kaj pa prihajajoči Python 3.12?
• Različice odvisnosti: Vaša aplikacija se lahko zanaša na knjižnice, kot so Django, Pandas ali Requests. Ali se bo pokvarila, če ima uporabnik nekoliko starejšo ali novejšo različico teh paketov?
• Operacijski sistemi: Ali vaša koda pravilno obravnava poti datotek in sistemske klice v sistemih Windows, macOS in Linux?
• Arhitekture: Z vzponom procesorjev na osnovi ARM (kot je Apple Silicon) postaja testiranje na različnih arhitekturah CPE (x86_64, arm64) vse bolj pomembno.

Poslovni razlogi za strategijo več okolij

Vlaganje časa v nastavitev te vrste testiranja ni samo akademska vaja; ima neposredne poslovne posledice:

• Zmanjšuje stroške podpore: Z zgodnjim odkrivanjem težav z združljivostjo preprečite poplavo zahtevkov za podporo uporabnikov, katerih okolij niste predvideli.
• Povečuje zaupanje uporabnikov: Programska oprema, ki zanesljivo deluje v različnih nastavitvah, se dojema kot kakovostnejša. To je ključnega pomena tako za knjižnice odprte kode kot za komercialne izdelke.
• Omogoča lažje nadgradnje: Ko je izdana nova različica Pythona, jo lahko preprosto dodate v svojo testno matriko. Če testi uspejo, veste, da ste jo pripravljeni podpreti. Če ne uspejo, imate jasen, izvedljiv seznam, kaj je treba popraviti.
• Podpira globalne ekipe: Zagotavlja, da lahko razvijalec v eni državi, ki uporablja najnovejša orodja, učinkovito sodeluje z ekipo v drugi regiji, ki je morda na standardiziranem, nekoliko starejšem podjetniškem naboru.

Predstavljamo Tox: Vaš avtomatizacijski ukazni center

Tox je zasnovan tako, da elegantno reši to težavo. V svojem bistvu Tox avtomatizira ustvarjanje izoliranih virtualnih okolij Python, vanje namesti vaš projekt in njegove odvisnosti ter nato izvaja vaše definirane ukaze (kot so testi, linterji ali gradnje dokumentacije).

Vse to nadzoruje ena sama, preprosta konfiguracijska datoteka: tox.ini.

Začetek: Namestitev in osnovna konfiguracija

Namestitev je preprosta s pip:

pip install tox

Nato ustvarite datoteko tox.ini v korenu vašega projekta. Začnimo z minimalno konfiguracijo za testiranje proti več različicam Pythona.

Primer: Osnovni tox.ini

[tox]
min_version = 3.7
isolated_build = true
envlist = py38, py39, py310, py311

[testenv]
description = Zaženite glavni testni paket
deps = pytest
commands = pytest

Razčlenimo to:

• [tox] odsek: To je za globalne nastavitve Tox.
• min_version: Določa minimalno različico Tox, ki je potrebna za izvajanje te konfiguracije.
• isolated_build: Sodobna najboljša praksa (PEP 517), ki zagotavlja, da je vaš paket zgrajen v izoliranem okolju, preden je nameščen za testiranje.
• envlist: To je srce testiranja v več okoljih. To je z vejicami ločen seznam okolij, ki jih želite upravljati s Tox. Tukaj smo definirali štiri: eno za vsako različico Pythona od 3.8 do 3.11.
• [testenv] odsek: To je predloga za vsa okolja, definirana v envlist.
• description: Koristno sporočilo, ki pojasnjuje, kaj okolje počne.
• deps: Seznam odvisnosti, potrebnih za izvajanje vaših ukazov. Tukaj potrebujemo samo pytest.
• commands: Ukazi za izvajanje znotraj virtualnega okolja. Tukaj preprosto zaženemo izvajalnik testov pytest.

Za izvedbo tega se v terminalu pomaknite v korenski imenik vašega projekta in preprosto vnesite:

tox

Tox bo zdaj izvedel naslednje korake za vsako okolje v `envlist` (py38, py39, itd.):

1. Poiščite ustrezen tolmač Python v vašem sistemu (npr. `python3.8`, `python3.9`).
2. Ustvarite sveže, izolirano virtualno okolje znotraj imenika .tox/.
3. Namestite vaš projekt in odvisnosti, navedene pod `deps`.
4. Izvedite ukaze, navedene pod `commands`.

Če kateri koli korak v katerem koli okolju ne uspe, bo Tox prijavil napako in izstopil z ničelno kodo stanja, zaradi česar je popoln za sisteme neprekinjene integracije (CI).

Poglobljen pogled: Izdelava močnega tox.ini

Osnovna nastavitev je močna, vendar je prava čarovnija Toxa v njegovih prilagodljivih možnostih konfiguracije za ustvarjanje kompleksnih testnih matrik.

Generativna okolja: Ključ do kombinatoričnega testiranja

Predstavljajte si, da imate knjižnico, ki mora podpirati različice Django 3.2 in 4.2, ki se izvajajo na Python 3.9 in 3.10. Ročno definiranje vseh štirih kombinacij bi bilo ponavljajoče:

Ponavljajoč način: envlist = py39-django32, py39-django42, py310-django32, py310-django42

Tox ponuja veliko čistejšo, generativno sintakso z uporabo zavitih oklepajev {}:

Generativni način: envlist = {py39,py310}-django{32,42}

Ta ena vrstica se razširi na iste štiri okolja. Ta pristop je zelo razširljiv. Dodajanje nove različice Pythona ali različice Django je samo stvar dodajanja enega elementa na ustrezni seznam.

Faktorsko-pogojne nastavitve: Prilagajanje vsakega okolja

Zdaj, ko smo definirali našo matriko, kako povemo Tox, da namesti pravilno različico Django v vsakem okolju? To se naredi s faktorsko-pogojnimi nastavitvami.

[tox]
envlist = {py39,py310}-django{32,42}

[testenv]
deps =
    pytest
    django32: Django>=3.2,<3.3
    django42: Django>=4.2,<4.3
commands = pytest

Tukaj vrstica `django32: Django>=3.2,<3.3` pove Tox: "Vključi to odvisnost samo, če ime okolja vsebuje faktor `django32`." Podobno velja za `django42`. Tox je dovolj pameten, da razčleni imena okolij (npr. `py310-django42`) in uporabi pravilne nastavitve.

To je neverjetno močna funkcija za upravljanje:

• Odvisnosti, ki niso združljive s starejšimi/novejšimi različicami Pythona.
• Testiranje proti različnim različicam osrednje knjižnice (Pandas, NumPy, SQLAlchemy, itd.).
• Pogojna namestitev odvisnosti, specifičnih za platformo.

Strukturiranje vašega projekta poleg osnovnih testov

Robustna cevovodna kakovost vključuje več kot le izvajanje testov. Izvajati morate tudi linterje, preverjevalnike tipov in graditi dokumentacijo. Najboljša praksa je, da za te naloge definirate ločena okolja Tox.

[tox]
envlist = py{39,310}, lint, typing, docs

[testenv]
deps = pytest
commands = pytest

[testenv:lint]
description = Zaženite linterje (ruff, black)
basepython = python3.10
deps =
    ruff
    black
commands =
    ruff check .
    black --check .

[testenv:typing]
description = Zaženite statični preverjevalnik tipov (mypy)
basepython = python3.10
deps =
    mypy
    # vključite tudi druge odvisnosti s pomočmi za tipe
    django
    djangorestframework
commands = mypy my_project/

[testenv:docs]
description = Zgradite dokumentacijo
basepython = python3.10
deps = sphinx
commands = sphinx-build -b html docs/source docs/build/html

Tukaj je nekaj novega:

• Specifični odseki okolja: Dodali smo `[testenv:lint]`, `[testenv:typing]` in `[testenv:docs]`. Ti odseki definirajo nastavitve posebej za ta imenovana okolja, pri čemer preglasijo privzete vrednosti v `[testenv]`.
• basepython: Za ne-testna okolja, kot sta `lint` ali `docs`, jih pogosto ni treba izvajati v vsaki različici Pythona. `basepython` nam omogoča, da jih pripnemo na določen tolmač, zaradi česar so hitrejši in bolj deterministični.
• Čista ločitev: Ta struktura ohranja vaše odvisnosti čiste. Okolje `lint` namesti samo linterje; vaša glavna testna okolja jih ne potrebujejo.

Zdaj lahko zaženete vsa okolja z `tox`, določen nabor z `tox -e py310,lint` ali samo eno z `tox -e docs`.

Integracija Tox s CI/CD za avtomatizacijo v globalnem merilu

Izvajanje Tox lokalno je super, vendar se njegova prava moč sprosti, ko je integriran v cevovod neprekinjene integracije/neprekinjene namestitve (CI/CD). To zagotavlja, da se vsaka sprememba kode samodejno preveri v vaši celotni testni matriki.

Storitve, kot so GitHub Actions, GitLab CI in Jenkins, so kot nalašč za to. Lahko izvajajo vaše naloge v različnih operacijskih sistemih, kar vam omogoča, da zgradite celovito matriko združljivosti OS.

Primer: Potek dela GitHub Actions

Ustvarimo potek dela GitHub Actions, ki vzporedno izvaja naša okolja Tox v sistemih Linux, macOS in Windows.

Ustvarite datoteko na naslovu .github/workflows/ci.yml:

name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        python-version: ['3.8', '3.9', '3.10', '3.11']

    steps:
    - name: Check out repository
      uses: actions/checkout@v3

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}

    - name: Install Tox
      run: pip install tox tox-gh-actions

    - name: Run Tox
      run: tox -e py

Analizirajmo ta potek dela:

• strategy.matrix: To je jedro naše CI matrike. GitHub Actions bo ustvaril ločeno nalogo za vsako kombinacijo `os` in `python-version`. Za to konfiguracijo je to 3 operacijski sistemi × 4 različice Pythona = 12 vzporednih nalog.
• actions/setup-python@v4: Ta standardna akcija nastavi določeno različico Pythona, ki je potrebna za vsako nalogo.
• tox-gh-actions: To je uporaben vtičnik Tox, ki samodejno preslika različico Pythona v okolju CI v pravilno okolje Tox. Na primer, v nalogi, ki se izvaja na Python 3.9, se bo `tox -e py` samodejno rešil na izvajanje `tox -e py39`. To vam prihrani pisanje zapletene logike v vaši skripti CI.

Zdaj se vsakič, ko se koda potisne, vaša celotna testna matrika samodejno izvede v vseh treh glavnih operacijskih sistemih. Prejmete takojšnje povratne informacije o tem, ali je sprememba povzročila nezdružljivost, kar vam omogoča, da z zaupanjem gradite za globalno bazo uporabnikov.

Napredne strategije in najboljše prakse

Posredovanje argumentov ukazom z {posargs}

Včasih morate izvajalniku testov posredovati dodatne argumente. Na primer, morda želite zagnati določeno testno datoteko: pytest tests/test_api.py. Tox to podpira s substitucijo {posargs}.

Spremenite svoj `tox.ini`:

[testenv]
deps = pytest
commands = pytest {posargs}

Zdaj lahko Tox zaženete takole:

tox -e py310 -- -k "test_login" -v

-- loči argumente, namenjene Tox, od argumentov, namenjenih ukazu. Vse za tem bo nadomeščeno z `{posargs}`. Tox bo izvedel: pytest -k "test_login" -v znotraj okolja `py310`.

Nadzor spremenljivk okolja

Vaša aplikacija se lahko obnaša drugače glede na spremenljivke okolja (npr. `DJANGO_SETTINGS_MODULE`). Direktiva `setenv` vam omogoča nadzor nad temi znotraj vaših okolij Tox.

[testenv]
setenv =
    PYTHONPATH = .
    MYAPP_MODE = testing

[testenv:docs]
setenv =
    SPHINX_BUILD = 1

Nasveti za hitrejše izvajanje Tox

Ko vaša matrika raste, lahko izvajanja Tox postanejo počasna. Tukaj je nekaj nasvetov za pospešitev:

• Vzporedni način: Zaženite `tox -p auto`, da Tox vzporedno izvaja vaša okolja z uporabo števila razpoložljivih jeder CPE. To je zelo učinkovito na sodobnih računalnikih.
• Selektivno ustvarjanje okolij: Privzeto Tox ponovno uporablja okolja. Če se vaše odvisnosti v `tox.ini` ali `requirements.txt` spremenijo, morate Toxu povedati, da ponovno zgradi okolje iz nič. Uporabite zastavico za ponovno ustvarjanje: `tox -r -e py310`.
• Predpomnjenje CI: V svojem cevovodu CI/CD predpomnite imenik .tox/. To lahko bistveno pospeši naslednje izvajanje, saj odvisnosti ne bo treba prenesti in namestiti vsakič, razen če se spremenijo.

Globalni primeri uporabe v praksi

Razmislimo, kako to velja za različne vrste projektov v globalnem kontekstu.

Scenarij 1: Knjižnica za analizo podatkov odprte kode

Vzdržujete priljubljeno knjižnico, zgrajeno na Pandas in NumPy. Vaši uporabniki so podatkovni znanstveniki in analitiki po vsem svetu.

• Izziv: Podpirati morate več različic Python, Pandas, NumPy in zagotoviti, da deluje na strežnikih Linux, prenosnikih macOS in namiznih računalnikih Windows.
• Rešitev Tox: envlist = {py39,py310,py311}-{pandas1,pandas2}-{numpy18,numpy19} Vaš `tox.ini` bi uporabil faktorsko-pogojne nastavitve za namestitev pravilnih različic knjižnice za vsako okolje. Vaš potek dela GitHub Actions bi preizkusil to matriko v vseh treh glavnih operacijskih sistemih. To zagotavlja, da uporabnik v Braziliji, ki uporablja starejšo različico Pandas, dobi enako zanesljivo izkušnjo kot uporabnik na Japonskem v najnovejšem naboru.

Scenarij 2: Podjetniška aplikacija SaaS s knjižnico odjemalcev

Vaše podjetje s sedežem v Evropi ponuja izdelek SaaS. Vaše stranke so velika, globalna podjetja, od katerih mnoga uporabljajo starejše različice operacijskih sistemov in Python za dolgoročno podporo (LTS) zaradi stabilnosti.

• Izziv: Vaša razvojna ekipa uporablja sodobna orodja, vendar mora biti vaša knjižnica odjemalcev povratno združljiva s starejšimi podjetniškimi okolji.
• Rešitev Tox: envlist = py38, py39, py310, py311 Vaš `tox.ini` zagotavlja, da vsi testi uspejo v Python 3.8, kar je morda standard pri veliki stranki v Severni Ameriki. S samodejnim izvajanjem tega v CI preprečite, da bi razvijalci po nesreči uvedli funkcije, ki uporabljajo sintakso ali knjižnice, ki so na voljo samo v novejših različicah Pythona, s čimer preprečite drage napake pri uvajanju.

Zaključek: Pošiljajte z globalnim zaupanjem

Testiranje v več okoljih ni več razkošje; je temeljna praksa za razvoj visokokakovostne, profesionalne programske opreme. S sprejetjem avtomatizacije s Tox spremenite ta zapleten izziv v poenostavljen, ponovljiv postopek.

Z definiranjem podprtih okolij v eni sami datoteki tox.ini in njeno integracijo s cevovodom CI/CD ustvarite močna vrata kakovosti. Ta vrata zagotavljajo, da je vaša aplikacija robustna, združljiva in pripravljena za raznoliko, globalno občinstvo. Lahko prenehate skrbeti zaradi strašne težave "deluje na mojem računalniku" in začnete pošiljati kodo z zaupanjem, da bo delovala na vsakem računalniku, ne glede na to, kje so na svetu.